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ROBOTIC LIBRARY COMMUNICATION PROTOCOL 
BACKGROUND OF THE INVENTION 

5 1. Technical Field: 

The present invention relates generally to the field 
of data processing systems, and specifically to an 
automated data storage library. The present invention 
relates still more particularly to a method and system 
10 for communicating among robotic mechanisms in an 
automated data storage library utilizing a robotic 
library communication protocol. 

2. Description of Related Art: 

15 Automated data storage libraries incorporate one or 

more robotic mechanisms for moving data cartridges around 
within the library. These robots typically move about 
utilizing one or more rails on which the robots reside. 
One known library system delivers power to the robots 

20 utilizing these rails. 

Movement and the actions of these robots are 
typically controlled by a controller computer included in 
the library. The controller computer and the robots of 
the library are typically connected directly to each 

25 other in order to transmit data among the computer and 
the robots. 

The controller is a fixed computer attached to the 
frame of the library and directs the motions of the 
robots. The robots are mobile machines within the 
30 library that receive their commands from the controller. 

Therefore, a need exists for a method and system for 
transmitting communications using a power transmission 
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means among robotic mechanisms in an automated data 
storage library utilizing a robotic library communication 
protocol . 
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SUMMARY OF THE INVENTION 

A method and system are disclosed for transmitting 
data among robots and a controller computer system within 
5 an automated robotic library. A robotic library 

communication protocol is described for communicating 
among the robotic mechanisms and the controller computer 
system. The robotic library communication protocol 
defines multiple fields for each packet including a 

10 preamble field that describes a predetermined preamble 
value that is equal to a particular value. Data is 
transmitted among the robotic mechanisms and the 
controller computer system utilizing the robotic library 
communication protocol. Each packet that conforms to the 

15 protocol includes only the preamble value in the preamble 
field. Power is provided to the robotic mechanisms 
utilizing a power signal. Data that has been encoded 
according to the protocol is transmitted to the robotic 
mechanisms using the power signal. 

20 The above as well as additional objectives, 

features, and advantages of the present invention will 
become apparent in the following detailed written 
description. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

The novel features believed characteristic of the 
invention are set forth in the appended claims. The 
5 invention itself, however, as well as a preferred mode of 
use, further objectives and advantages thereof, will best 
be understood by reference to the following detailed 
description of an illustrative embodiment when read in 
conjunction with the accompanying drawings, wherein: 

10 Figure 1 depicts an automated robotic data storage 

library in accordance with the present invention; 

Figure 2a is a block diagram that depicts a packet 
that conforms to a robotic library communication protocol 
in accordance with the present invention; 

15 Figure 2b is a table that illustrates each field in 

a robotic library communication protocol and the size and 
location of each field in accordance with the present 
invention; 

Figure 2c depicts one byte of an asynchronous serial 
20 data signal in accordance with the present invention; 

Figure 3 illustrates a high level flow chart which 
depicts encoding a message using a robotic library 
communication protocol to produce an asynchronous serial 
data signal, modulating the encoded message on top of a 
25 power signal, and transmitting the modulated signal in 
accordance with the present invention; 

Figure 4 depicts a high level flow chart which 
illustrates receiving a modulated signal, extracting an 
asynchronous serial data signal, and decoding the 
3 0 asynchronous serial data signal using a robotic library 
communication protocol in accordance with the present 
invention; and 



5 

Docket No. 2003-111-TAP 

Figure 5 is a detailed block diagram of a computer 
system that may be used to implement one of the computer 
systems or controller computer system of Figure 1 in 
accordance with the present invention. 
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DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT 

A preferred embodiment of the present invention and 
its advantages are better understood by referring to the 
5 figures, like numerals being used for like and 
corresponding parts of the accompanying figures. 

The present invention is a method and system for 
transmitting data among robots and a controller computer 
system within an automated robotic library. A robotic 

10 library communication protocol is described for 

communicating among the robotic mechanisms and the 
controller computer system. The robotic library 
communication protocol defines multiple fields for each 
packet including a preamble field that describes a 

15 predetermined preamble value that is equal to a 

particular value. Data is transmitted among the robotic 
mechanisms and the controller computer system utilizing 
the robotic library communication protocol. Each packet 
that conforms to the protocol includes only the 

20 particular preamble value in the preamble field. 

In addition to the preamble field, the robotic 
communications protocol also defines for each packet a 
destination address field for storing an address of the 
intended recipient of the packet, a source address field 

25 for storing the address of the sender of the packet, a 

type field for storing an identification of a type of the 
packet, a data field for storing user data, and an error 
checking field for storing an error checking character. 
Power is provided to the robotic mechanisms 

30 utilizing a power signal that is delivered to each robot 
utilizing one or more rails on which the robots move 
about. When data is to be transferred among the robots 
and controller computer system, the data is encoded using 
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the robotic communication protocol. Once encoded, the 
data is converted to a stream of bytes that is then 
converted to an asynchronous data signal. This 
asynchronous data signal is then modulated on top of the 
5 power signal. The modulated signal is transmitted to the 
robotic mechanisms using the power delivery system. In 
the preferred embodiment, the power delivery system is a 
pair of rails on which the robots reside and move about. 
Robots then receive the modulated signal. They 

10 demodulate the signal to separate the power signal used 
to power the robots from the data signal. The received 
data signal is converted into a series of bytes. If the 
series of bytes includes a preamble that is set to the 
predetermined value as defined by the robotic 

15 communications protocol, the rest of the data signal is 
decoded according to the protocol. If the series of 
bytes does not include a preamble that is set to the 
predetermined value, ^the data signal is discarded and not 
processed. 

2 0 The modulator/demodulators that are described below 

may be used to transmit or receive data. Although the 
controller computer system is described as transmitting a 
message and each robot is described as receiving a 
message, the controller computer system and each robot 
25 are all capable of either transmitting data or receiving 
data using the methods described herein. That is, a 
robot may use the method described below with reference 
to Figure 3 to transmit a message, and the controller 
computer may use the method of Figure 4 to receive that 

3 0 message sent by a robot. 

Figure 1 depicts a robotic library 100 in accordance 
with the present invention. Robotic library 100 includes 
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a robot 102 and a robot 104 that travel via a power 
transmission means, such as a rail 106. A computer 
controller 108 is utilized to control the movement of 
robots 102, 104 and to transmit and receive data to and 
5 from robots 102, 104 utilizing rail 106. 

Power is provided by a power signal 110 output by 
power supply 112 to robots 102, 104 utilizing rail 106. 
Robot 102 receives power utilizing brushes 114. Robot 
104 receives power utilizing brushes 116. 

10 The present invention provides a method and system 

for transmitting data among robots 102, 104 and computer 
controller 108 utilizing rail 106. Data is transmitted 
utilizing rail 106 by modulating a data signal on top of 
the power that is provided via rail 106. Computer 

15 controller 108 provides a message that is encoded 

utilizing an asynchronous data signal 118. Asynchronous 
data signal 118 is provided from controller computer 108 
to modulator/demodulator 120. Modulator/demodulator 
(MODEM) 120 also receives power signal 110. MODEM 120 

2 0 generates a modulated signal 122 by modulating 

asynchronous data signal 118 on top of power signal 110. 
MODEM 120 converts every digital zero of the signal 118 
into a 5.5 MHz signal, and every digital one into a 6.6 
MHz signal. Thus, MODEM 120 provides to rail 106 

25 modulated signal 122 which delivers both power and data 
to rail 106. Rail 106 transmits modulated signal 122 to 
robots 102, 104. 

Each robot receives the modulated signal via brushes 
which transmit the modulated signal to a 

30 modulator/demodulator included in the robot. For 

example, robot 102 receives modulated signal 122 via 
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brushes 114 which provides the received modulated signal 
122a to a modulator/demodulator 124 that is included in 
robot 102 . Modulator/demodulator 124 demodulates 
modulated signal 122a to separate asynchronous data 
5 signal 118a from the power signal. MODEM 124 converts 
every 5.5 MHz signal into a digital zero, and every 6,6 
MHz signal to a digital one. Asynchronous data signal 
118a is provided to a computer 126 that is also included 
in robot 102. Computer 126 then converts the 

10 asynchronous data signal 118a to create a stream of 
bytes. Computer 126, as described in detail below, 
determines whether the stream of bytes conforms to the 
communication protocol. If the stream of bytes conforms 
to the communication protocol, computer 126 processes the 

15 remaining data. If the stream of bytes does not conform 
to the communication protocol, computer 126 discards and 
thus ignores the remaining data. 

Robot 104 receives modulated signal 122 via brushes 
116 which provides the received modulated signal 122b to 

2 0 a modulator/demodulator 128 that is included in robot 
104. Modulator/demodulator 12 8 demodulates received 
modulated signal 122b to separate asynchronous data 
signal 118b from the power signal. Asynchronous data 
signal 118b is provided to a computer 13 0 that is also 

25 included in robot 104. Computer 130 then converts the 
asynchronous data signal 118b to create a stream of 
bytes. Computer 130, as described in detail below, 
determines whether the stream of bytes conforms to the 
communication protocol. If the stream of bytes conforms 

30 to the communication protocol, computer 130 processes the 
remaining data. If the stream of bytes does not conform 
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to the communication protocol, computer 130 discards and 
thus ignores the remaining data. 

Figure 2a is a block diagram that depicts a packet 
that conforms to a robotic library communication protocol 
5 in accordance with the present invention. Each packet 
200 that conforms to the protocol will include six 
different fields. The first field is a preamble field 
202 in which a predefined preamble value is stored. The 
second field is a destination address (DA) field 204 in 

10 which a destination address is stored. The third field 
is a source address (SA) field 206 in which a source 
address is stored. The fourth field is a type field 208 
in which a type is stored. The fifth field is a data 
field 210 in which message data is stored. The sixth 

15 field is a CRC field 212 in which an error checking 
character, such as a CRC, is stored. 

Figure 2b is a table that illustrates each field in 
a robotic library communication protocol and the size and 
location of each field in accordance with the present 

2 0 invention. The first field is the preamble field. The 
destination address field follows the preamble field. 
The source address field follows the destination field. 
The type field follows the source field. The data field 
follows the type field. And, the CRC field follows the 

25 data field. 

The preamble field is the first field in each packet 
and therefore includes a zero offset from the start of 
each packet. The preamble is two bytes long and is a 
predetermined value. According to the preferred 

30 embodiment, the predetermined value is ''0x4B 0x53". All 
packets that conform to the robotic library communication 
protocol will include this predetermined value stored in 
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the preamble field. Those skilled in the art will 
recognize that any other value may be used in the 
preamble field so long as the value is predetermined and 
all packets that conform to the protocol include this 
5 value as the preamble in the preamble field. 

The next field in each packet is a destination 
address field that is six bytes long and offset from the 
start of the packet by the two bytes of the preamble 
field. The address of the intended recipient is stored 

10 in this field. 

The next field in each packet is a source address 
field that is six bytes long and offset from the start of 
the packet by eight bytes, the two bytes of the preamble 
and the six bytes of the destination address. The 

15 address of the sender of the packet is stored in this 
field. 

The next field in each packet is a type field that 
is two bytes long and offset from the start of the packet 
by 14 bytes, the two bytes of the preamble, the six bytes 

20 of the destination address, and the six bytes of the 

source address, A type is used to identify the type of 
the packet. For example, a packet may be a maintenance 
packet or a regular IP communication packet. 

The next field in each packet is a data field that 

25 is between 0 and 1500 bytes long depending on the length 
of the data. The user data is stored in the data field. 
The data field is offset from the start of the packet by 
16 bytes, the two bytes of the preamble, the six bytes of 
the destination address, the six bytes of the source 

3 0 address, and the two bytes of the type field. 

The last field in the packet is a CRC field which is 
two bytes long and stores a CRC of the packet. A CRC is 
calculated using all of the fields from the preamble 
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through the user data field. According to the preferred 
embodiment, the CRC is calculated using the following 
formula where x is equal to the string including the 
value of the preamble, destination address, source 
5 address, type, and user data: x^^ + x^^ + x^^ + x^^ + x^^ + 
x^2 + + x^*^ + x« + x' + x^ + x^ + x^ + x^ + x^ 

Figure 2c depicts one byte of an asynchronous serial 
data signal in accordance with the present invention. 
Each packet of data is divided into bytes. The bytes 

10 that make up the packets are converted into a stream of 
bytes. The stream of bytes is then converted into an 
asynchronous serial data signal 220. Each byte is 
represented by 11 bits of data including a start bit 222, 
eight bits of data 224, and two stop bits 226. Start bit 

15 222 indicates the start of another byte of signal 200 
while stop bits 226 indicate the end of the byte. The 
actual data of the byte is represented by bits 224. The 
start of the next byte of data in the signal 220 is 
indicated by the start bit 228 of the next byte. 

20 Figure 3 illustrates a high level flow chart which 

depicts encoding a message using a robotic library 
communication protocol to produce an asynchronous serial 
data signal, modulating the encoded message on top of a 
power signal, and transmitting the modulated signal in 

25 accordance with the present invention. The process 

starts as depicted by block 300 and thereafter passes to 
block 302 which illustrates a determination of whether or 
not to send a message to a robot using the robotic 
library communication protocol via the robot power 

30 signal. If a determination is made that no message is to 
be sent, the process passes back to block 302. 
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Referring again to block 302, if a determination is 
made that a message is to be sent to a robot using the 
robotic library communication protocol via the robot 
power signal, the process passes to block 304 which 
5 depicts generating a message to send. Next, block 306 
illustrates encoding the message using the robotic 
library communication protocol to produce one or more 
communication packets that conform to the protocol. Each 
packet includes a two-byte preamble set to a 
10 predetermined value, a destination address that 

identifies the intended recipient, a source address that 
identifies the sender, a type that identifies the type of 
packet, user data, and an error checking code such as a 
CRC. 

15 Next, block 308 depicts converting the packets into 

a stream of bytes. Thereafter, block 310 illustrates 
converting the stream of bytes into an asynchronous data 
signal that has one start bit and two stops bits that 
delimit each byte of the stream of bytes. Block 312, 

20 then, depicts modulating the asynchronous data signal on 
top of the rail power signal. Thereafter, block 314 
illustrates transmitting the modulated signal to the 
rail. The process then terminates as depicted by block 
316. 

25 Figure 4 depicts a high level flow chart which 

illustrates receiving a modulated signal, extracting an 
asynchronous serial data signal, and decoding the 
asynchronous serial data signal using a robotic library 
communication protocol in accordance with the present 

30 invention. The process starts as depicted by block 400 
and thereafter passes to block 402 which illustrates 
receiving the modulated signal that includes the 
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asynchronous data serial signal modulated on top of the 
rail power signal at a robot. Next, block 404 depicts 
demodulating the modulated signal to extract the 
asynchronous serial data signal. 
5 Block 406, then, illustrates converting the 

asynchronous serial data signal to a stream of bytes. 
Thereafter, block 408 depicts a determination of whether 
or not the first two bytes of the stream of bytes equal 
the predetermined preset preamble value. If a 

10 determination is made that the first, two bytes of the 
stream of bytes do not equal the predetermined preset 
preamble value, the process passes to block 410 which 
illustrates the occurrence of an error. The stream of 
bytes is then discarded. The process passes back to 

15 block 402. 

Referring again to block 408, if a determination is 
made that the first two bytes of the stream of bytes do 
equal the predetermined preset preamble value, the 
process passes to block 412 which illustrates decoding 

2 0 the remaining bytes according to the robotic library 

communication protocol. The process passes back to block 
402. 

Figure 5 illustrates a detailed block diagram of a 
computer system that includes the present invention in 

25 accordance with the present invention. Computer system 
500 may be a symmetric multiprocessor (SMP) system 
including a plurality of processors 501, 502, 503, and 
504 connected to system bus 506. Alternatively, a single 
processor system may be employed. Also connected to 

30 system bus 506 is memory controller/cache 508, which 

provides an interface to a plurality of memory subsystems 
560-563. I/O bus bridge 510 is connected to system bus 
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506 and provides an interface to I/O bus 512. Memory 
controller/cache 508 and I/O bus bridge 510 may be 
integrated as depicted. 

Data processing system 500 may be a logically 
5 partitioned data processing system. Thus, data 

processing system 500 may have multiple heterogeneous 
operating systems (or multiple instances of a single 
operating system) running simultaneously. Each of these 
multiple operating systems may have any number of 

10 software programs executing within it. Data processing 
system 500 may be logically partitioned such that 
different I/O adapters 520-521, 528-529, 536, and 548-549 
may be assigned to different logical partitions. 

Peripheral component interconnect (PCI) Host bridge 

15 514 connected to I/O bus 512 provides an interface to PCI 
local bus 515. A number of Input/Output adapters 520-521 
may be connected to PCI bus 515 through PCI to PCI bridge 
516. Typical PCI bus implementations will support 
between four and eight I/O adapters (i.e. expansion slots 

20 for add- in connectors) . Each I/O Adapter 520-521 

provides an interface between data processing system 500 
and input/output devices such as, for example, other 
network computers, which are clients to data processing 
system 500. 

25 PCI host bridge 530 provides an interface for PCI 

bus 531 which is connected to PCI-PCI bridge 532. PCI- 
PCI bridge 532 is coupled to a PCI I/O adapter 536 
through PCI bus 533. 

An additional PCI host bridge 522 provides an 

30 interface for an additional PCI bus 523. PCI bus 523 is 
connected to a plurality of PCI I/O adapters 528-52 9 
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through a PCI-PCI bridge 524 and PCI bus 526-527. Thus, 
additional I/O devices, such as, for example, modems or 
network adapters may be supported through each of PCI I/O 
adapters 528-529. In this manner, data processing system 
5 500 allows connections to multiple network computers. 
A memory mapped graphics adapter 548 may be 
connected to I/O bus 512 through PCI Host Bridge 540 and 
PCI-PCI bridge 542 via PCI buses 541, 544 and 545 as 
depicted. 

10 Those of ordinary skill in the art will appreciate 

that the hardware depicted in Figure 5 may vary. For 
example, other peripheral devices, such as optical disk 
drives and the like, also may be used in addition to or 
in place of the hardware depicted. The depicted example 

15 is not meant to imply architectural limitations with 
respect to the present invention. 

It is important to note that while the present 
invention has been described in the context of a fully 
functioning data processing system. Those of ordinary 

20 skill in the art will appreciate that the processes of 

the present invention are capable of being distributed in 
the form of a computer readable medium of instructions 
and a variety of forms and that the present invention 
applies equally regardless of the particular type of 

25 signal bearing media actually used to carry out the 
distribution. Examples of computer readable media 
include recordable- type media, such as a floppy disk, a 
hard disk drive, a RAM, CD-ROMs, DVD-ROMs, and 
transmission-type media, such as digital and analog 

30 communications links, wired or wireless communications 
links using transmission forms, such as, for example, 
radio frequency and light wave transmissions. The 
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computer readable media may take the form of coded 
formats that are decoded for actual use in a particular 
data processing system. 

The description of the present invention has been 
5 presented for purposes of illustration and description, 
and is not intended to be exhaustive or limited to the 
invention in the form disclosed. Many modifications and 
variations will be apparent to those of ordinary skill in 
the art. The embodiment was chosen and described in 
10 order to best explain the principles of the invention, 
the practical application, and to enable others of 
ordinary skill in the art to understand the invention for 
various embodiments with various modifications as are 
suited to the particular use contemplated. 



